Block diagrams are used to model real-world systems. Historically, engineers and scientists have utilized time-based block diagram models in numerous scientific areas such as Feedback Control Theory and Signal Processing to study, design, debug, and refine dynamic systems. Dynamic systems, which are characterized by the fact that their behaviors change over time, are representative of many real-world systems. A dynamic system (either natural or man-made) is a system whose response at any given time is a function of its input stimuli, its current state, and the current time. Such systems range from simple to highly complex systems. Physical dynamic systems include a falling body, the rotation of the earth, bio-mechanical systems (muscles, joints, etc.), bio-chemical systems (gene expression, protein pathways), and weather and climate pattern systems. Examples of man-made or engineered dynamic systems include: a bouncing ball, a spring with a mass tied on an end, automobiles, airplanes, control systems in major appliances, communication networks, audio signal processing, nuclear reactors, and a stock market.
A block diagram model of a dynamic system is represented schematically as a collection of blocks interconnected by lines that represent signals. A signal represents the input and output of a dynamic system. Each block represents an elemental dynamic system. A line emanating at one block and terminating at another signifies that the output of the first block is an input to the second block. Each distinct input or output on a block is referred to as a port. Signals correspond to the time-varying quantities represented by each line connection and are assumed to have values at each time instant at which the connecting blocks are enabled. The source block of a signal writes to the signal at a given time instant when its system equations are solved. The destination blocks of this signal read from the signal when their system equations are being solved.
Time-based block diagram models may be thought of as relationships between signals and state variables representative of a dynamic system. The solution (computation of system response) of the model is obtained by evaluating these relationships over time. The time-based relationship may start at a user-specified “start time” and end at a user-specified “stop time”, or the evaluations may continue indefinitely. Each evaluation of these relationships is part of a time step. Signals represent quantities that change over time, and these quantities are defined for all points in time between the block diagram's start and optional stop time. The relationships between signals and state variables are defined by sets of equations represented by blocks. These equations define a relationship between the input signals, output signals, state, and time.
It should be noted that the term “block diagram” as used herein is also used to refer to other graphical modeling formalisms. For instance, flow-charts are block diagrams of entities that are connected by relations. Flow-charts are used to capture process flow and are not generally suitable for describing dynamic system behavior. Data flow block diagrams are diagrams of entities with relations between them that describe a graphical programming paradigm where the availability of data is used to initiate the execution of blocks, where a block represents an operation and a line represents execution dependency describing the direction of data flowing between blocks. It will be appreciated that a block diagram model may include entities that are based on other modeling domains within the block diagram. A common characteristic among these various forms of block diagrams is that they define semantics on how to execute them.
As noted above, professionals from diverse areas such as engineering, science, education, and economics build computational models of dynamic systems in order to better understand system behavior as it changes with the progression of time. The computational models aid in building “better” systems, where “better” may be defined in terms of a variety of performance measures such as quality, time-to-market, cost, speed, size, power consumption, robustness, etc. The computational models also aid in analyzing, debugging and repairing existing systems (be it the human body or the anti-lock braking system in a car). As systems become more complex, an increasingly large amount of time and effort is involved in creating accurate, detailed models. These models are typically hybrid dynamic systems that span a variety of domains, including continuous dynamics and discrete behavior, physical connections, and event-driven states. To add to the complexity, these systems may be depicted in a number of ways, including dynamic or physics block diagrams, finite state machines, and hand-written or automatically generated computer code.
To identify a cause when a model does not execute as expected, or when its execution time needs to be improved, detailed information about its execution has to be available. Unfortunately, this level of detail is not usually available as the display and the accessibility of such detailed information introduces significant execution overhead. Instead, the model can be run in a distinct ‘debug’ mode, where the additional information is exposed, but at the cost of execution speed. In order to debug the system behavior, the modeler must not only understand the inner workings of each piece of a model, but also how these different pieces interact. For example, the dynamic model could cause a transition in the finite state machine, or part of the dynamic system may be implemented in computer code, which is simulated in conjunction with the remainder that is modeled in the block diagram.
Currently, debugging tools exist that allow modelers to debug individual portions of their model from different modeling domains. Individual existing debuggers can walk the user through a dynamic block diagram, or show the transition order in a finite state machine, or step through running computer code. Unfortunately, the individual debuggers do not work together as a seamlessly integrated tool over multiple domains. This presents a number of problems. The modeler has to manually transition from one debugger to the next, losing the context of where they are in their system. Additionally, conventional debuggers provide no information about how the different domains of the system work together.